Philosophie de la programmation

 B ien sûr, le titre est un peu exagéré: je ne compte pas exposer ici positivement une «philosophie de la programmation». C'est juste pour discuter un peu de la manière dont on programme, de ce qui est bon et ce qui n'est pas bon de faire, selon les cas.

Pour mon compte, je manie habituellement deux langages, le Pascal et l'assembleur, et ai quelques lumières sur les langages C, Cobol, GAP (RPG), Lisp, Basic (linéaire et structuré), et quelques autres. Les langages, il y en a de cinq grands types: linéaires, structurés, modulaires, cycliques et mixtes. Sauf les langages linéaires, tous sont en réalité mixtes, en ce sens que tous sont susceptibles de traitements linéaires, tous les modulaires sont basiquement structurés, tous les cycliques implicitement structurables. Et bien sûr, les mixtes sont mixtes… Ce qui les différencie est surtout que des langages structurés, modulables et cycliques on présume qu'ils useront rarement ou jamais de leurs potentialités autres. Par exemple, le Pascal comporte des instructions du même type que le Basic linéaire (GOTO, BREAK, EXIT) qui autorisent à interrompre un traitement pour effectuer ce qu'on appelle des branchements, ou d'arrêter intempestivement au milieu d'un traitement; de même, si le langage Modula est, comme son nom l'indique, modulaire, on peut programmer avec lui de la même manière qu'en Pascal. Ou qu'en Basic. Rares sont les langages stricts, je ne connais guère que l'Ada qui soit purement modulaire et ne permette pas de traitements linéaires.

Parmi les langages linéaires, le plus connus sont l'assembleur, le Basic linéaire, le Fortran et le Cobol. Les trois derniers sont en quelque sorte des assembleurs “évolués”, si ça peut exister, où les traitements sont séquentiels; le basic est un langage général, le Fortran «orienté scientifique», et le Cobol un langage dédié au traitement de données de gestion financière et comptable. Actuellement, les deux derniers ne sont pratiquement plus utilisés pour créer de nouvelles applications, et on se contente de maintenir les programmes existants, en les améliorant s'il y a lieu; le basic aussi n'est que rarement utilisé dans ses versions linéaires. Le seul langage structuré vraiment répandu est le Pascal; il y eut bien des choses intéressantes développées dans les années 1960 et 1970, notamment le Prolog (un langage conçu pour la réalisation d'applications «d'intelligence artificielle»), et comme indiqué, le Modula est utilisable comme langage structuré, mais le grand concurrent dans le domaine, le C, qui n'est pas proprement un langage structuré mais en a bien des traits, les a écrasés. La programmation modulaire correspond pour beaucoup à ce qu'on appelle aujourd'hui «programmation objet», même s'il doit en exister d'autres, les seuls langages de la catégorie que je connaisse sont ADA et Modula, qui doivent beaucoup aux réfléxions qui menèrent à la création du langage Pascal. Pour les langages cycliques, le plus ancien et plus efficace est un langage curieux, le LISP, inventé en 1960 il me semble, qui a quatre particularités: on n'y différencie pas les données et les traitements; sauf une petite douzaine de commandes de base, rien n'y est fixé; les calculs sont représentés sous la forme dite de la notation polonaise, avec l'opérateur en premier, la liste des opérandes ensuite; c'est le seul langage interprété s'exécutant plus vite que nombre langages compilés[1]. Sinon, la quasi totalité des langages cycliques sont du genre dit «propriétaire», des langages propres à une ligne de machines spécifiques à un constructeur, et que l'on ne trouvera pas ailleurs. Ils ont pour trait commun d'être dédiés aux applications de gestion. J'en connais quelques-uns, le plus connu est le RPG ou GAP, développé par IBM et fonctionnant uniquement sur ses mini-ordinateurs.

Les langages les plus couramments utilisés sont le C, le Basic structuré, le Pascal, l'assembleur, plus toute la série de ce qu'on appelait il y a une dizaine d'années les 4GL ou L4G (fourth generation languages, langages de quatrième génération), et qu'on appellerait aujourd'hui «visuels» (en fait, on ne les appelle pas, ils sont…), les divers Visual C, Visual Basic, Delphi, etc. Et bien sûr, toute la série de langages qui servent à générer des pages HTML dites dynamiques, et les «langages de scripts», qui ne sont pas à proprement parler des langages de programmation. Les langages modulaires ou cycliques sont d'usage rare: il y a des sortes de sectes qui s'attachent à développer des programmes en Modula ou en LISP, mais pour le commun des mortels, c'est de trop haute volée, ils se contentent des langages les plus habituels. Cela dit, programmer en LISP vaut le coup, contrairement aux autres langages de programmation, celui-ci requiert d'avoir une compréhension totale de ce qu'on écrit, de le saisir dans sa globalité et dans tous ses détails. Intellectuellement très gratifiant.

Je le disais, mon langage favori est le Pascal. Un langage intéressant, parce qu'il vous force à écrire des programmes bien conçus, où tout ce qu'on utilise est clairement défini, et où les parties formant un ensemble cohérent et réutilisable forment des sous-programmes. Donc, un langage structuré. Cependant, la variante la plus courante du Pascal, le Turbo-Pascal, ainsi que ses dérivés (Free Pascal, Virtual Pascal, etc.) n'a plus grand chose à voir avec le langage originellement défini par son inventeur, Klaus Wirth: à considérer les choses, il semble plus proche du langage C que du Pascal, et en outre il s'est vu adjoindre il y a une dizaine d'années des capacités de programmation objet qui le rapprochent cette fois des langages modulaires. Ces versions «évoluées» de Pascal ont aussi pour particularité de permettre d'inclure au sein du programme des parties de code assembleur, chose prévue dans la version originale, mais d'une manière rustique, la commande “inline” permettant d'insérer, non pas de l'assembleur, mais du code machine. Je connais bien une personne — et une seule — capable d'écrire du code machine comme moi j'écris le français (peut-être mieux que je n'écris le français), mais pour le programmeur moyen, on ne peut pas dire que ce soit vraiment génial… Il y avait aussi la possibilité des «includes», mais cette fois le problème venait de ce que l'on devait savoir à quelle adresse exacte dans le fichier binaire se trouvait le début de la procédure assembleur à utiliser. L'assembleur «inline» (à ne pas confondre avec la commande “inline”) et une autre amélioration due à Borland, la société qui créa Turbo-Pascal, les «unités», simplifièrent considérablement ce genre de choses.

Le Pascal n'a pas que des avantages: pour produire des programmes «denses», avec des fichiers exécutables de la taille la plus réduite possible, les meilleures solutions restent l'assembleur, et juste après vient le langage C; pour ne pas trop se casser la tête avec l'écriture de code, les meilleures solutions sont la programmation «visuelle» et les AGL (ateliers de génie logiciel); avec ces deux solutions, on «dessine» ou l'on décrit son programme, et le logiciel se chargera de créer l'application à partir de «briques logicielles». Problème, avec ces méthodes on obtient des fichiers qui, pour des fonctionnalités équivalentes, sont quatre ou cinq fois plus gros que leur équivalent en Pascal, et cinq à sept fois plus qu'avec l'assembleur ou le C.

Comme expliqué dans la note 1, les questions de taille des fichiers et de vitesse d'exécution n'ont plus le caractère crucial de l'époque où les disques durs avaient une taille réduite et la mémoire vive était limitée. Mais un programmeur sérieux tendra à vouloir «optimiser» son programme, terme signifiant à la fois en réduire la taille et en améliorer la vitesse de traitement. Ce n'est pas une simple question de, disons, probité professionnelle: si l'on s'attache à optimiser un programme, on doit bien réfléchir à ce qu'il doit faire et comment, ce qui a pour résultat principal de considérablement limiter les erreurs de programmation, et pour l'utilisateur, les risques de «plantage».

Maintenant, les choses ne sont pas si évidentes: par exemple, réaliser un programme destiné à fonctionner sous Windows, ou sous Linux dans un environnement “X-Window”, ou sous OS/2, est peu compatible avec une conception soignée et optimale. Avec Linux, ou tout autre UNIX, les choses sont plus claires, en ce sens qu'on parle explicitement d'un «environnement»; par contre, Windows et OS/2 sont présentés comme des systèmes d'exploitation pour ordinateurs, ce qu'ils ne sont pas. Autant que je le sache, le seul système d'exploitation «graphique» existant est celui fourni sur les ordinateurs Apple. Comme “X-Window”, Windows est un environnement graphique s'appuyant sur un système d'exploitation, variant selon les versions: Windows 95 et Windows 98 s'appuient sur le système MSDOS, Windows NT et Windows XP, sur un système non spécifié qu'on pourrait nommer “NT”, «New Technology», et Windows 2000 sur un système mixte, à base de MSDOS “étendu” (32 bits) avec des extensions NT.

Ce qui amène a une distinction: il y a trois sortes de systèmes fonctionnant sur les ordinateurs PC: 16 bits, 32 bits et 64 bits. Ceci réfère principalement à la donnée de base exploitée par ces systèmes, mais a plusieurs implications fonctionnelles: en fait, un système 16 bits peut aussi manipuler des données 32 bits ou 64 bits, par contre, il ne peut pas gérer plus que 8 fois 64 Ko de mémoire, soit 512 Ko; avec des magouilles, on peut doubler cette capacité, mais c'est tout. Les systèmes 32 bits peuvent, quant à eux, gérer jusq'à seize blocs de 2Go de mémoire, et pour les systèmes 64 bits, je vous laisse imaginer… Comme rien n'est simple, on peut superposer des systèmes, ou des simili systèmes, 16 bits et 32 bits. Par exemple, sur ma machine le système de base est un MSDOS 16 bits, qui sert essentiellement à démarrer un second système 32 bits, lequel à son tour démarre l'environnement Windows 95.

Ce qui explique pourquoi la programmation Windows est complexe: en fait, un «programme Windows» n'est pas, du point de vue d'un programmeur de la vieille école, un véritable programme, mais quelque chose comme une collection de «macrocommandes» qui seront «interprétées» par le «gestionnaire de tâches» de l'environnement Windows, lequel passera le résultat de son interprétation au système 32 bits sous-jacent, qui selon les cas, le traitera lui-même, ou le traduira à son tour ça pour le soumettre au système 16 bits. Ce qui fait qu'un programme Windows consiste à 90% ou 95% en une collection de commandes absconses même pour le programmeur le plus affûté, et au plus 5% à 10% de programmation proprement dite.

Je vous parle de ça sans l'avoir vraiment expérimenté. Parce que justement je suis un programmeur de la vieille école, et que mes programmes sont tous écrits pour le DOS, que ce soit celui de base ou le DOS 32 bits qui fait fonctionner Windows. J'ai, pourrait-on considérer, une «éthique de l'ordinateur» et une «philosophie de la programmation». Éthique, manière de dire, philosophie, manière de dire…

L'éthique ou ce qui y ressemble est du même ordre que celle qui me guide dans le reste de mes considérations sur la société: pourquoi faire mal avec dix ce qu'on pourrait faire bien avec un ou deux ? Ce qui consiste en ceci: j'ai trois ordinateurs, dont le plus récent date de 1995. J'ai ces trois ordinateurs, non parce que je serais un «fou des ordinateurs», mais parce qu'au contraire, je déteste dépenser des sous pour ces engins: l'un m'a «coûté» 30 €, les deux autres furent gratuits. Je n'ai jamais dépensé plus de 300 € pour acheter un ordinateur. Cette fois, non parce que je serais avare, ou au moins très économe, mais parce que m'intéresse plus l'usage que le symbole. C'est un peu — et même beaucoup — ce qui sépare certains acheteurs d'automobiles d'occasion de certains acheteurs de véhicules neufs: pourquoi acheter cinq ou dix fois plus cher un objet qui nominalement est “plus”, mais qui effectivement, dans un usage quotidien, se révèle “égal” ? Par exemple, un argument de vente «puissant» (cas de le dire) des vendeurs d'automobiles est la vitesse de leurs véhicules; mais à quoi sert une autombile capable d'aller à plus de 200 km/h, sachant que la majeure partie des routes ont une limite de vitesse de 90 km/h, que même les autoroutes sont limitées à 130 km/h, et qu'enfin pour un citadin (ce qu'est en majorité l'acheteur d'automobiles européen), les contextes d'utilisation habituels de son véhicule le feront circuler à 50 km/h ou moins ? Ce qui compte, finalement, est d'avoir un véhicule adapté aux besoins plutôt que «le plus» ceci ou cela — en général, «le plus puissant».

Pour les ordinateurs, c'est pareil: les ordinateurs les plus récents sont réputés «plus puissants»[2] que les précédents, de même pour les systèmes d'exploitation. Mais, «plus puissants» absolument ou relativement ? Je discute de ça de diverses manières dans divers textes, et généralement en faisant une comparaison avec les autos, parce que ça me paraît signifiant: nominalement, une Ferrari est, je ne sais pas, dix, quinze, vingt fois «plus puissante» qu'une 2CV; effectivement elle se révèlera en moyenne entre une fois et delie et deux fois «plus puissante». Parce que le contexte habituel d'utilisation des deux véhicules n'est pas un circuit de course mais une rue de ville ou une route de campagne. Or, les vendeurs d'ordinateurs tendent à vouloir vous faire acheter la plus récente — et plus chère — Ferrari là où une 2CV ferait le même usage. Étant plutôt opposé aux tendances lourdes de nos sociétés productivistes dites «de consommation» à aller vers un «toujours plus» plutôt qu'un toujours mieux, j'ai la même considération pour ce qui est des ordinateurs: je préfère dépenser entre rien et 300 € qu'entre 1.000 et 3.000 € pour un instrument dont l'aspect utilitaire m'intéresse plus que la valeur sociale (j'ai «le dernier», «le plus puissant»). En plus, mon éthique m'évite des déceptions perpétuelles: mon ordinateur n'étant dès le départ ni le plus récent, ni le plus puissant, je ne risque jamais la déception et l'aigrissement de caractère auxquels s'expose l'acheteur de l'ordinateur «le plus», puisque tous les six mois environ, il y a un nouvel ordinateur «plus que plus», qui fatalement fait glisser l'ancien «le plus» vers la catégorie des «moins», et assez vite, des «moins que moins». Dans ce domaine comme en tout autre, j'ai une philosophie hédoniste, ce qui ne consiste pas, comme on veut le faire croire, à rechercher tous les plaisirs, mais à viser à la satisfaction en n'entreprenant ou ne se procurant que ce qu'on peut se permettre, et de prendre ses limites en bonne part.

Ma philosophie de la programmation est évidente: pourquoi faire compliqué ? Si vous avez jeté un œil à la page où je propose de télécharger quelques-uns des programmes de mon cru, vous aurez constaté que ce sont essentiellement des petits «modules» qui se contentent de réaliser une, deux, parfois trois tâches simples. Je ne méconnais pas le confort d'utilisation des programmes Windows, maintenant, quand je fais la maintenance de mon ordinateur, ou quand je veux faire des «traitements par lots», c.-à-d. des actions s'appliquant à un grand nombre de fichiers, je le fais «sous DOS». Parce qu'il préférable pour moi de faire des choses simples dans un environnement simple que des choses complexes dans une environnement complexe. Considérez par exemple qu'après avoir essayé différents programmes de création de pages HTML, j'ai renoncé à ceux dits WYSIWYG (What You See Is What You Get, ce que vous voyez est ce que vous obtiendrez), ou «graphiques», et utilise un programme frustre mais complet et efficace, l'éditeur de texte HTMLEDIT, pour trois raisons principales: à résultats visuels et fonctionnels équivalents, les programmes WYSIWYG produisent des fichiers quatre à dix fois plus gros que ceux faits avec mon bon vieux HTMLEdit; je ne fais jamais — ou fais rarement — des pages si complexes que j'aie besoin d'un programme qui réalise des opérations complexes à ma place; enfin, il est plus facile de déterminer ce qui ne va pas dans une page HTML quand on en voit ce qu'on nomme «la source», qu'en en voyant «la cible»: avec un éditeur WYSIWYG, on travaille, non pas sur la page Web, mais sur son image, sa représentation finale, ce qui fait que quand une page s'affiche bizarrement ou se comporte autrement que souhaité, il n'est pas toujours évident de déterminer où est l'erreur; avec un éditeur de texte comme HTMLEdit, il y a des «marqueurs de syntaxe» qui colorent le texte différemment selon les commandes HTML qui s'y trouvent, et on même une couleur «erreur de syntaxe»: en parcourant rapidement le texte, on voit assez vite où il y a une partie colorée autrement qu'on l'imaginait, ou un emplacement «syntaxe incorrecte».

Ce qui nous ramène à la programmation: celle pour Windows est plutôt “WYSIWYG”, ou “visuelle”: en général, le programmeur Windows, sauf pour les fanatiques de tapage de code abscons, font leurs applications en «mode visuel», qui est l'exact inverse de la programmation classique et consiste en ceci: avec un AGL — un «atelier de génie logiciel» — “visuel”, on “dessine” son application; je mets le terme entre guillemets, alors que c'est littéralement ce qu'on fait, soit: avec une sorte d'éditeur graphique on créera une interface utilisateur (une «fenêtre de programme») avec sa barre de menu, ses boutons, sa barre de titre, sa barre d'état, etc., bref, proprement on la dessine. En une deuxième phase on va «associer» les éléments de la fenêtre programme à des actions prédéfinies, et seulement en un troisième temps, faire proprement de la programmation, c.-à-d. écrire les parties de code “non standard”, qui feront la particularité du programme. En réalité, il se peut très bien qu'on en reste à la deuxième phase, en ce sens qu'on peut très bien réaliser une application qu'il n'utilise que des fonctions standards, et ne fasse rien qui nécessite de la programmation de la part du concepteur (par exemple, si l'on veut faire une petite application qui se contente d'afficher des listes de fichiers, et si l'on clique sur l'un de l'afficher «selon son format» en utilisant les afficheurs de Windows, tout cela n'utilise que des «briques logicielles» prédéfinies, et ne nécessite aucune programmation particulière).

D'un côté, c'est pratique: où il aurait fallu des semaines ou des mois pour réaliser une application selon la vieille méthode, on peut le faire en quelques jours. De l'autre, c'est problématique à deux titres: les programmes générés sont énormes, considérant les services rendus[3]. Et surtout, du fait que pour l'essentiel le code du programme est, dira-t-on, invisible au concepteur, il ne sait en fait par réellement ce que fait son programme, ni comment. Un programme de ce genre est assez similaire à un énarque ou à un polytechnicien: il connaît peu de choses mais dans beaucoup de domaines; il en a beaucoup dans la tête, mais l'utilise rarement; il a des bonnes méthodes générales de gestion, mais connaît très mal les méthodes propres à un domaine particulier; et quand il se plante, c'est toujours «la faute au système». Et bien sûr, comme tout bon énarque, on le paie beaucoup trop cher pour ce qu'il fait…

Mon exemple de la note 3 (à propos, le programme s'appelle NotePad, est gratuit et peut se télécharger ici) montre qu'on peut réaliser des programmes Windows “propres”, sans fioritures, sans ajout de code inutile; mais on se retrouve dans la situation pré-L4G, pré-“Visual”, où le programmeur doit prendre en charge l'écriture de tout le code de son application, ce qui fait que ça lui prendra beaucoup plus de temps pour la réaliser — les semaines et les mois évoqués, plutôt que les jours.

Cela dit, j'ai une autre raison de préférer la programmation à l'ancienne, ce qu'on appelle «l'élégance», qui bien sûr se rapporte plutôt à ce qu'on appelle élégance dans les sciences exactes qu'à l'élégance vestimentaire. Il y a l'aspect utilitaire des programmes, clairement discernable par l'utilisateur justement, mais pour les programmeurs, du moins ceux de mon genre, qui sont venus à la programmation par goût plutôt que par nécessité ou ambition (travailler dans un «secteur porteur»), cette question de l'élégance est assez importante; cela consiste essentiellement à obtenir un certain résultat avec le minimum d'actions. Par exemple, dans un programme j'avais écrit la séquence suivante: 

		IF (N = Y)
		   THEN X := X - 1;

Ce qui revient, un fois cela compilé, en sept instructions minimales:

  1. Prendre la valeur N;
  2. Prendre la valeur Y;
  3. Comparer N à Y;
  4. Si N = Y, Aller à 9
  5. Prendre la valeur X
  6. Prendre la valeur 1
  7. Ajouter à la valeur X
  8. Mettre le résultat dans X
  9. [instruction suivante]

Un peu plus tard, je reprends mon programme, et je me dis, tu peux faire plus simple: le test “(N = Y)” donnera comme résultat, soit 0, soit 1; en attribuant directement la valeur du test à “X”, tu obtiendras le même résultat en «plus élégant». Ce qui donna: 

		X := X - Ord(N = Y);

“Ord” n'est pas une instruction, mais ce qu'on appelle une directive de compilation: normalement, les compilateurs Pascal refusent d'attribuer une valeur d'un certain type à une variable d'un autre type; un test comme “(N = Y)” est implicitement de type “booléen” (logique), ma variable “X” est de type “entier” (numérique); “Ord(<valeur>)” indique au compilateur de prendre en compte, non le type du test, mais sa valeur ordinale. Le résultat du changement est le suivant:

  1. Prendre la valeur N;
  2. Prendre la valeur Y;
  3. Comparer N à Y;
  4. Prendre la valeur X
  5. Ajouter (résultat comparaison) à la valeur X
  6. Mettre le résultat dans X
  7. [instruction suivante]

On pourra me dire que ça ne fait pas une différence formidable. Ce à quoi je répondrai ceci:

  • Il y a la question de l'élégance de la version Pascal;
  • Passer de 9 à 7 instructions, fait un gain de quelques de 22%; appliqué à tout un programme ça commence à faire…
  • Il se trouve que les instructions qui prennent le plus de temps à un ordinateur, sont les celles dites «de branchement» [“aller à” tel endroit du programme], et celles qui manipulent ce qu'on appelle des constantes, comme 1, contrairement à N, Y et X qui sont des variables.

Conclusion, outre la plus grande élégance de la formule, j'ai réduit le code généré de plus de 20%, et le temps de traitement d'au moins 35%. D'où l'intérêt de «l'élégance»: ça fait des programmes plus efficaces à tous points de vue.

Or, avec la programmation visuelle, par nécessité on ne peut améliorer de beaucoup l'élégance des programmes, donc les rendre plus efficaces, puisque le code généré dépend pour l'essentiel de segments hors de contrôle du programmeur.

En fait, il y eut un curieux glissement, dans la décennie 1990: vers la fin de la précédente décennie, on présentait comme la voie prometteuse, la «programation du futur», celle dite programmation objet, couplée aux fameux «langages de quatrième génération». Or les langages L4G qui se développèrent, s'appuyant effectivement sur des langages objet ou «orientés objet», c.-à-d. des langages autres (Pascal, C, Basic) pourvus d'extensions qui permettaient de programmer «objet», en vinrent tous, pour des questions de simplicité de mise en œuvre, à la «programmation événementielle», qui à y regarder, est la version tout juste modernisée des langages cycliques ou de gestion «à la papa». Ce qui fait leur — relative — modernité, c'est plutôt les «interfaces graphiques» (Windows, OS/2, X-Window) et les fonctionnalités qui leurs sont liées, que leurs fonctionnalités propres.

Un peu d'explication: l'idée générale de la programmation objet est de permettre la conception de modules autonomes, les «objets», intégrant des données et des fonctions; jusque-là, pas de différence avec la programmation modulaire. Mais les objets sont «recouvrables» et permettent «l'héritage». Par exemple, on crée un objet “figure”, qui consiste en une donnée “point” et une fonction “afficher”. Puis on crée un objet “cercle”, héritière de “figure”, ou la fonction “afficher” sera «recouverte», pour permettre d'afficher une série de données “point” jusqu'à former un cercle, puis une fonction “cercle-plein”, héritière de “cercle”, et qui… L'avantage de ce type de programmation est bien sûr d'éviter d'avoir à réécrire une fonction autant de fois qu'on veut un résultat. Outre cela, la norme édictée par les inventeurs de la programmation objet indique que pour tout objet doivent exister un «constructeur» “initialiser” et une fonction inverse, un «destructeur» “supprimer”, qui ne créera «l'objet» que quand nécessaire, et le détruira quand il ne sert plus.

Les descriptions c'est bien, l'illustration c'est mieux. Voici ce que pourraient être des objets “point” et “rectangle”: 

OBJET Point =
    Donnee : entier = 0;
    CONSTRUCTEUR Init;
        DEBUT
        FIN
    FONCTION Dessiner(X, Y : entier);
        DEBUT
          Aller-a(X, Y); Afficher(Donnee);
        FIN
    FONCTION Colorer(Couleur : entier);
        DEBUT
          Donnee = Couleur;
        FIN
    DESTRUCTEUR Fin;
        DEBUT
        FIN
FIN
OBJET Rectangle = OBJET(Point)
    FONCTION Dessiner(X, Y, Droite, Bas : Entier);
        M : Entier;
        DEBUT
            POUR M ALLANT DE X A X+Droite
                Point.Dessiner(M, Y)
                Point.Dessiner(M, Bas)
            FIN POUR
            POUR M ALLANT DE Y A Y+Bas
                Point.Dessiner(X, M)
                Point.Dessiner(Droite, M)
            FIN POUR
        FIN
FIN

Un exemple est un exemple, d'évidence, pour réaliser ce que présenté, on n'a pas vraiment besoin de la programmation objet… C'est simplement pour faire comprendre les mécanismes: dans la deuxième fonction, les «constructeur» et «destructeur» ne sont pas indiqué, ni la donnée “Donnee” et la fonction “Couleur”, puisque qu'elles sont les mêmes que dans l'objet «parent»; par contre, la fonction “Dessiner” est «recouverte», et ne correspond pas à l'original, celle de “Point” acceptant deux paramètres, celle de “rectangle” en acceptant quatre; enfin, on voit que la «fonction parente» peut être «réutilisée» dans son «héritière». Le double intérêt de la programmation objet est de permettre d'organiser les fonctions et données d'un programme de manière très compacte, et de n'avoir pas à réécrire sans fin les mêmes instructions. Donc, en bonne logique, un programme écrit en langage objet devrait être plus compact et plus rapide qu'un programme «classique». Or, ce n'est pas ce qui se passe. Plus exactement, ce n'est pas ce qui se passe dans le couplage programmation objet / programmation événementielle.

La programmation événementielle est essentiellement une programmation cyclique, où le programme généré «attend un événement»; ce qui consiste en: attendre une saisie clavier, un mouvement ou un clic de souris, l'activation du modem, d'un scanner, bref, toute intervention de l'utilisateur (même distant) via un périphérique; en réponse à cet événement, et selon le contexte, une action automatique sera lancée. Un programme Windows moyen, c'est à tout le moins 80% d'événements, 20% de traitement. Ce qui ne signifie pas, bien sûr, qu'utiliser un programme Windows revient à passer 80% de son temps à attendre que les actions événementielles se déroulent, en fait ça peut être moins, mais ça peut aussi être plus — certains programmes, notamment les afficheurs d'images, ne font en fait pratiquement que de l'événementiel. Non, ce que signifie mon 80%/20% est que dans un programme Windows, au moins 80% du code est dévolu à la gestion des événements, au plus 20% aux traitements proprement dits. Pour une raison simple: un «objet événement» est une chose très éloignée de l'optimum. Considérons un objet «événement clavier»: dans votre programme, vous en placerez un, par exemple, pour gérer le traitement d'un appel à la barre de menu; dans votre menu, vous aurez quatre, cinq, sept options, et pour chaque option, deux «raccourcis-claviers»; donc, votre «événement clavier» traitera au plus une quinzaine de cas; mais ça ne se passe pas comme ça, lors de la création du programme: en fait, le compilateur “visuel” placera un énorme objet «événement clavier» en état de traiter toutes les possibilités, qui sera «encapsulé» dans un procédure ad hoc traitant les seuls cas qui vous intéressent, et exécutant les traitement souhaités. D'où ce rapport disproportionné entre la part qui, dans un logiciel normal (un traitement de texte ou un tableur, p. ex.) traite les moindres actions — les événements — et celle qui fait les traitements proprement dits.

Considérez que ce type de programmation n'est pas inintéressant, loin de là, c'est ce qui permet, par exemple, la correction orthographique automatique en cours de frappe, ou, comme dans Excel, la proposition de saisie automatique en fonction de valeurs semblables dans la même colonne, ou dans Word le remplacement de “oe” par “œ” à la volée. Il y a un problème, pour moi, mais lié à la réunion des outils de programmation visuelle, de la programmation objet et de la programmation événementielle, et lié aussi, sinon à la paresse des concepteurs de ces AGL, du moins au fait qu'ils travaillent toujours dans l'urgence (“on”, c.-à-d. le détenteur des droits, les pousse en permanence à sortir une «nouvelle» version histoire de brûler la concurrence).

[1] Cette notion fut en son temps cruciale, mais avec l'amélioration des performances des micro-ordinateurs, a perdu de sa pertinence: les langages interprétés sont ceux où les programmes ne sont pas autonomes, et nécessitent un programme «interpréteur» pour être exécutés; ceux compilés sont, après écriture de ce que l'on appelle «code source», analysés par un compilateur, et transformés en un programme exécutable autonome et, dans les temps anciens, plus petit que le fichier source. Dans les époques antédiluviennes (avant 1990) où les processeurs, avec au mieux 1,2 millions de transistors, tournaient au plus à 66Mhz, où les disques durs de «grande taille» faisaient dans les 200 Mo, ma foi la vitesse d'exécution et la taille des fichiers avaient une assez grande importance. Prenez mon cas: avec mon viel ordinateur 486DX et son disque de 1Go, si je devais accepter la gestion des pages Web par Flash, Java, DirectX et autres «langages» très gourmands en place disque et en temps machine, je passerais 80% de mon temps de connexion à attendre que ça veuille seulement commencer, et mon système, lui, passerait son temps à me dire, espace disque insuffisant… Incidemment, les langages «compilés» actuels n'ont plus rien à voir, en réalité, ils génèrent ce qu'en 1990 on aurait consiéré comme des programmes interprétés.
[2] Je discute longuement de cette notion assez floue de «puissance des ordinateurs» dans une analyse intitulée «La Loi de Moore», pour conclure en gros que, comme pour les automobiles, cette mise en avant de la «puissance» est plus un argument de vente publicitaire qu'une notion techniquement validable…
[3] Pour illustration, un éditeur de texte simple, selon qu'il sera écrit en assembleur ou en C “pur”, comme disent les programmeur, ou qu'il le sera en Visual Assembler ou en Visual C, fera, ici moins de 100Ko, là entre 1,5Mo et 2Mo, pour la même fonctionnalité. Et je parle ici d'un constat: j'ai récupéré sur Internet trois programmes comparables, visant à remplacer le Bloc-notes; les deux écrits en “Visual” quelque chose faisaient effectivement, l'un environ 1,5Mo, l'un environ 2Mo; en revanche, le troisième, celui que j'utilise, faisait 93Ko. Ce qui a une triple importance: il occupe quinze à vingt fois moins d'espace disque, en fonction, il utilise environ cinq fois moins d'espace mémoire, et surtout, du fait qu'il n'y a pas tout un tas de code inutile, il fonctionne deux à trois fois plus vite….